Skip to content

fix issue where port is not propagated down to connection URL#971

Merged
asfgit merged 2 commits into
apache:trunkfrom
tonybaloney:fix_port_propagation
Jan 9, 2017
Merged

fix issue where port is not propagated down to connection URL#971
asfgit merged 2 commits into
apache:trunkfrom
tonybaloney:fix_port_propagation

Conversation

@tonybaloney
Copy link
Copy Markdown
Contributor

Noticed that a custom port does not roll down properly to the connection class.

Also, there is still an outstanding issue that unless the port is 443, the connection will be assumed as plain HTTP.

E.g. setting port as 9999 but Secure=True will still issue a plain HTTP connection

@tonybaloney
Copy link
Copy Markdown
Contributor Author

mergey merge

@asfgit asfgit merged commit 8b3b1cb into apache:trunk Jan 9, 2017
asfgit pushed a commit that referenced this pull request Jan 9, 2017
@Kami
Copy link
Copy Markdown
Member

Kami commented Jan 9, 2017

Good catch.

Comment thread libcloud/httplib_ssl.py
def __init__(self, host, port, **kwargs):
self.host = '{0}://{1}'.format(
self.host = '{0}://{1}{2}'.format(
'https' if port == 443 else 'http',
Copy link
Copy Markdown
Member

@Kami Kami Jan 9, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we have access to secure argument here?

Because if we do, it looks like we still don't correctly handle one scenario - https on a non default port (protocol is not set correctly). For example, secure=True, port=8080 should result in https://<host>:8080.

Or am I missing something?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Edit: Sorry, I should have read the description better - you already addressed this scenario there.

Also checked the code and it looks like "secure" argument is not passed to the constructor right now so yeah, we would need to change some code to make it work.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Kami yes, absolutely. That's a separate PR. I'm back to making one change at a time!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants